Description

Fixes #2105.

Hi, when Badger is running in in-memory mode (Options.InMemory = true), SSTables exist entirely in memory and don't have an underlying file. There were two error paths in (*Table).block that accessed the table's filename directly to produce a more descriptive error. Since in-memory tables don't have a file handle, those paths could dereference a nil pointer and panic.

This shows up whenever a block read fails on an in-memory table. A few real situations that trigger it:

• Bad RAM / bit flips -- in-memory tables have no checksums, so a single flipped bit in a compressed block makes decompression fail. The reporter was running on an ARMv7 with 1GB of RAM, which makes this kind of corruption much more likely.
• Interrupted memtable flush -- if a flush into an in-memory L0 table is cut short by an OOM or signal, the table bytes end up half-written. The next read of that table hits the panic instead of returning a clean error.
• Compression mismatch -- building a table with one compression algorithm (say, zstd) and reading it back with a different one causes decompression to fail, which takes the same panicking path.

The fix keeps things minimal. Filename() now returns a stable, convention-matching name derived from the table ID when there's no file handle, and the two direct filename lookups in block() go through Filename() as well. On-disk tables are completely unaffected.

Added two tests:

• TestInMemoryTableBlockErrorNoPanic -- corrupts a compressed in-memory table and asserts block() returns an error instead of panicking. Reproduces the exact panic from the issue on main before the fix.
• TestInMemoryTableFilename -- verifies the synthesized name returned for an in-memory table.

Checklist

• Code compiles correctly and linting passes locally
• Tests added for new functionality, or regression tests for bug fixes added as applicable